AWS再入門2018 AWS Well-Architected Framework編

こんにちは。池田です。先日、自動ドアを通過中に扉が閉まってきて激突した拍子に、メガネのレンズが傷だらけになってしまっていたのですが、昨日やっと新しいメガネが手元に届きました。視界がクリアなのって素敵なことですね。

AWS再入門2018 プロマネや営業のためのAWS Monthly Calculator入門編に登場してもらったところ、ごく一部で微妙な人気をいただいている架空の人物「太郎くん」。せっかくなので今回も登場してもらおうと思います。

はじめに

先週見積もりを作成したお客様から「AWSへの移行を進めたいので、いくつか教えて欲しいことがある」と呼び出された太郎くん、見積もりに含めなかった各種オプション料金の資料などを調べて会いにいきました。そこでお客様から言い渡された質問の内容とは...

もくじ

• 質問1: 「ルートアカウントを社内で使い回すつもりだが、楽な方法はないか？」
• 質問2: 「構築チームは協力会社も含めたメンバーになるが、セキュリティ的に不安がある。どうしたらいい？」
• 質問3: 「アプリケーションやスクリプトからもAWSリソースにアクセスしたいが可能か？」
• 質問4: 「各種リソースを操作したログの取得は可能か？」
• 質問5: 「クラウドのセキュリティってどうするのか」
• 質問6: 「先日見積もってもらったリソースは適切か」
• 質問7: 「コスト削減のアドバイスをして欲しい」
• 質問8: 「コストの管理はどうしたらいい？」
• 質問9: 「バックアップとかどうしたらいい？」
• 質問10: 「そもそも障害対策とかどうなってるの？」
• まとめ

EC2オプション料金資料の束を抱えた太郎くんは白目になりそうでしたが、週末に視聴していた「AWS White Belt Online Seminar」で紹介されていた「AWS Well-Architected Framework」のことを思い出し、机の下で小さくガッツポーズをとりました。そして、ブックマークしていたセミナー資料のスライドをお客様に見せながら説明を始めました。

Q1: ルートアカウントを社内で使い回す

太郎くんはスライドにある通りに、まずルートアカウントについて説明しました。

• アカウント作成時に利用したメールアドレスとパスワードでログインするユーザであること
• そのアカウントにおける全ての権限を持っていること（リソースへのアクセス、操作、各種サービスに関することなど）
• AWSが公式に「ルートアカウントは極力利用しない」ことを推奨していること

その上でルートアカウントを使い回すリスクについても説明しました。「例えるなら、オフィスの施錠から会社の金庫や銀行口座まで全て自由にできる権限を共有するようなものです。」このひとことでお客様は納得してくれたようで、太郎くんは一安心しました。そして、代替手段としてのIAMについても説明を続けました。

• IAM（AWS Identity and Access Management）は、AWSリソースへのアクセスを安全に制御する仕組みであること
• 認証情報の管理としてユーザ名とパスワード、MFAの利用などの設定、制限ができること
• アクセス権の管理手段としてグループ、ロール、ポリシーがあり対象や目的に応じて使い分ける必要があること

Q2: セキュリティ的に不安がある

ルートアカウントの共有はしないことにしましたが、協力会社を含め複数人が関わる場合はどうしたら良いのかという話になったので、太郎くんはIAMユーザとIAMグループの利用を提案しました。

• IAMユーザとは
• AWSを操作するためのユーザであり、マネジメントコンソールやAPI、AWS CLIを利用する際に使う
• ユーザ名とパスワード、アクセスキーが必要
• 各AWSリソースに対するアクセス権をポリシーとして細かく設定できる
• IAMグループとは
• IAMユーザをまとめる単位
• IAMユーザと同様にアクセス権をポリシーとして設定できるが、対象はグループ単位になる
• ユーザとグループをうまく組み合わせて利用する
• 可能な限り最小限の権限を持たせた状態から始め、業務上必要な権限が不足している場合にのみ付与していく
• 複数人に必要な権限はユーザごとではなく、グループに付与していく
• 強い権限や特権を付与する必要があるユーザにはMFAを有効化して不正利用などの対策を行う
• 認証情報の漏洩対策として定期的なローテーションを実施する

Q3: アプリケーションやスクリプトからの利用

お客様は一部のスクリプトなどを協力会社など外部委託先に制作してもらい、それを利用して一部のAWSリソースを制御する計画のようでした。太郎くんはソースコードの共有によるセキュリティ事故事例を研修で学んでいたので、それについて説明しました。

• スクリプトやアプリケーション内部に認証情報を埋め込んではいけない
• 認証情報を埋め込んだスクリプトなどが誤操作や漏えいなどによって、第三者に知られてしまった場合に不正利用されるリスクがある
• EC2上のスクリプトからRDSへアクセスするなどといった場合にはIAMロールを設定すること
• IAMロールの認証情報はSecurity Token Service（STS）で生成し、自動的にローテーションされるため維持管理が省力化できる
• OSやスクリプト、アプリケーションに認証情報を埋め込む必要がなくなるため、漏洩のリスクが低減できる
• gitリポジトリを利用したソースコード管理を行なっている場合はgit-secretsの利用を徹底する
• 認証情報を含んだソースコードをgitリポジトリにコミットすることを防ぐためのツール
• AWSAccessKeyIdやAWSSecretKeyなどが含まれていないかをチェックできる

Q4: 各種リソースを操作したログの取得

様々なセキュリティ認証などを取得、維持しているお客様は万が一の内部犯行や外部からの不正利用が発生した際の調査方法についても気にしているようでした。そこで太郎くんはAWS CloudTrailを利用することを提案しました。

• AWS CloudTrailは、ユーザのAPI操作など各種アクションを取得し保存する仕組み
• セキュリティインシデント発生時の分析に利用できるうえに、内部犯行の抑止力として期待できる
• 取得したログをCloudWatch Logsへ転送し、監視することも可能
• AWSとしては「全リージョンでの有効化と必要に応じた期間の設定」を推奨している
• 取得可能なログはできるだけ有効化しておく
• ELB、S3、CloudFront、API Gateway、VPC Flow Logsなど
• より多くの脅威からの保護を実施したい場合には、Amazon GuardDutyの活用を検討する
• CloudTrail、VPC Flow Logsなどのログを分析し、脅威を検知する仕組み
• エージェントの導入などを行わずに利用できるフルマネージドサービス
• 脅威を検知した場合は、推奨される対策も提示される
• 処理したログの量に応じた従量課金となることに注意が必要

Q5: クラウドのセキュリティ

ふわっとした質問ではありますが、そういう聞き方になるよなぁと思いつつもAWSのセキュリティって、それだけでセミナー開催したり書籍化できそうなくらい色々あるんだよなぁとも感じている太郎くん、今日は素直に資料に掲載されいる部分だけを説明しました。

• 各リソースにおいて、外部からのアクセスを本当に必要なものだけに限定する
• 不要なポートの閉塞、不要なサービスなどを停止することによるリスクの低減（当然、これだけで万全という話ではない）
• リソースごとに適切な制御を行う
• ネットワークならネットワークACLを利用する ・VPCサブネット単位でのファイアウォール（ステートレス） ・セキュリティのベースとして利用
• VPC内の各リソース（EC2やRDSインスタンスなど）にはセキュリティグループを利用する ・インスタンス（グループ）単位に設定するファイアウォール（ステートフル） ・サーバの機能、用途に応じたセキュリティルールを設定する際に利用
• AWSが提供するセキュリティ対策サービスを利用する
• AWS WAF ・ウェブアプリケーションを不正/悪意のあるリクエストから保護するウェブアプリケーションファイアウォール ・SQLインジェクション攻撃やXSS攻撃など一般的な不正リクエストに対するルールを作成して利用 ・ALB（Application Load Balancer）とCloudFrontに設定が可能
• AWS Shield ・DDoS（分散サービス妨害攻撃）から保護するサービス ・レイヤー3、4における既知の攻撃から保護 ・デフォルトでSield Standardプランレベルの保護が適用されている ・より高度な保護を行いたい場合のためにShield Advancedプランが用意されている

Q6: 見積もったリソースは適切か

「ところで、先日見積もってもらったリソースは適切なのかい？」とお客様から聞かれた太郎くん、リソースを指定したのは僕じゃないぞ...と思いつつも説明を続けます。

• 適切なサイジング
• これからAWSへ移行させようとしているシステムの稼働状況を把握する ・既存システムのスペック ・各種リソースの使用率 ・それぞれの稼働時間 ・実際のパフォーマンスと期待値の比較
• AWSへ移行後も継続的な観察を行う ・AWS CloudWatchを使って、リソースの利用状況を把握する
• リソースの利用状況、使用率によってインスタンスファミリーやタイプを見直していく ・使用率が安定しており、必要なリソースが算出できているのであればRIを購入することでコスト削減が期待できる

Q7: コスト削減のアドバイス

最初からRIの購入を検討しているお客様にコスト削減のアドバイスを求められた太郎くん、さすがにこの資料だけでは回答に困ってしまいましたが、先日使った簡易見積もりツールを思い出しました。

• RIの利用
• 常時稼働しており、リソースの利用率も安定しているような場合はRIを継続的に利用する
• EC2から外部へ転送されるデータ量の圧縮
• 外部からEC2へ向けたインバウンドデータは無料だが、EC2から外部へ向けたアウトバウンドデータは階層化された従量制となっているため、画像や動画データの圧縮によりコスト削減が期待できるケースがある

太郎くんは無難な説明をした後に簡易見積もりツールの画面を見せ、今回利用を想定していないAWSサービスでも今後、他の既存システムをAWSへ移行していく際に利用する可能性もあり、その際には改めてそれぞれに適切なコスト削減策を提案することを伝えてお茶を濁し切り抜けました。

Q8: コストの管理

コストの管理方法って言われても、この前見積もったシステムだと毎月ほぼ同じだからそんなに心配しなくていいんだけどなぁ...と思いつつも、太郎くんは残りのシステムもAWSへ移行していったときのことを想定して説明をすることにしました。

• 特定のIAMユーザ（例えば経理担当者など）に対して、請求情報へのアクセス権を付与する（ルートアカウントによる操作が必要）
• ルートアカウントにより、コストエクスプローラーを有効にする
• 請求アラーム（Billing Alert）を利用して、閾値を越えた際に通知させる

※クラスメソッド メンバーズにご加入いただいている場合は、弊社独自の割引制度があるため、上記とは異なる方法になります。

Q9: バックアップについて

「バックアップはどうしたらいい？」という質問に太郎くんは思わず「取るに決まってるでしょ！」と心の中でツッコミを入れてしまいました。ちなみに、太郎くんの中では様々なツッコミネタに対してランクづけをして「ツッコミビリティ」と呼ぶ謎の習慣があるようで、今回はツッコミビリティ★★★☆☆というやや高めの評価だったようです。

• EC2に対するバックアップ
• AMI（Amazon Machine Image）の作成 ・構築後や改修前などのタイミングで作成することにより、トラブルが発生した際の切り戻しや復元に利用できる ・サービスや事業拡張などによってインスタンス数を増やしたい場合にも利用できる
• Amazon EBSのスナップショット取得
• アプリケーションの改修やOSの更新を行う前に取得しておくことで、復元が容易になる
• 上記2つの手段で取得したものから復元するテストを実施しておく
• RDSの自動バックアップ機能を活用する
• これについても復元テストを実施しておくと良い
• OS上で動作するスクリプトなどによる定期的なバックアップデータはS3へ保存させる
• せっかく保存したバックアップデータがOSのトラブルや操作ミスによって消えてしまっては意味がない

Q10: 障害対策

AWSにおける障害対策は多岐にわたっていることを理解している太郎くん、今回はEC2とRDSに限定することを前置きしつつ説明を続けます。

• 単一障害点を排除できる設計を心がける
• EC2インスタンスが1台停止してもサービスは停止しない（ようにみえる）構成とする ・複数AZにインスタンスを配置 ・Elastic Load Balancingの利用 ・Auto Scalingの利用 ・Auto Recoveryの利用
• RDSのマルチAZオプションを利用する ・同期レプリケーションと自動的なフェイルオーバーを提供 ・データの冗長化による可用性向上
• 要件とマッチするならマネージドサービスの利用を検討
• 様々な「管理からの解放」を求めるユーザの声から多くのサービスが開発、提供されている

まとめ

思っていたよりも長時間のプレゼンとなってしまいましたが、お客様はとても喜んでくれて太郎くんも満足したようです。AWSが公開しているホワイトペーパーを始めとした各種ドキュメントには、エンジニア向けのものばかりではなく、太郎くんのような営業職の人でも「知っててよかった！」という情報がたくさんあります。これからもそういった情報を整理しながら理解し、このブログを読んでくださる方々へ太郎くんとともにお伝えしていきたいと思います。